home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / sdkdigv7.zip / SDKV7N10.TXT < prev    next >
Text File  |  1993-12-30  |  6KB  |  126 lines
  1. Apparently-To: john.smith@gravis.com
  2.  
  3.  
  4. GUS Programmer's Digest     Thu, 30 Dec 93  4:31         Volume 7: Issue  10  
  5.  
  6. Today's Topics:
  7.                             Forte response
  8.  
  9. Standard Info:
  10.     - Meta-info about the GUS can be found at the end of the Digest.
  11.     - Before you ask a question, please READ THE FAQ.
  12.  
  13. ----------------------------------------------------------------------
  14.  
  15. Date: Wed, 29 Dec 93 18:30:53 CST
  16. From: chuth@lonestar.utsa.edu (Cornel H. Huth)
  17. Subject: Re: Forte response
  18.  
  19. > > Just who are they trying to scare? Developers like me? Take a hike, bozos.
  20.  
  21. > First of all, CONSTRUCTIVE criticism is always welcome. Comments like this
  22. > last sentence are neither appreciated or called for.
  23.  
  24. That's one line compared to several paragraphs. Heh. If you don't like it:
  25. tough tities.
  26.  
  27. > Its still wrong because nobody brought the error to our attention. It
  28. > is indeed flipped. The low nibble is the start fraction and the high
  29. > nibble is the end fraction. We'll fix it also.
  30.  
  31. And you don't know already? It's been like that since the beta SDK and that
  32. was a July 1992 publication. Do you even read/use your own SDK? I can't
  33. imagine so because it is, for practical purposes, useless. And even your
  34. above explanation is ambiguous. It's loop start fraction, not start fraction.
  35. Two separate things.
  36.  
  37. > > should not have left Canada as is. I would feel very uneasy about using
  38. > > any of the code in this SDK, to say the least. Actually, since I write
  39.  
  40. > As far as I know, there are no bugs in the SDK code. We use it for a lot
  41. > of stuff and don't have any problems. I would encourage people to use
  42.  
  43. Famous last words. The previous SDK (2.01) was competely useless to anyone
  44. not able to fix the numerous problems themselves. And this time 'round, not
  45. a single mention of any changes/fixes. No wonder you have all those bugs in
  46. there for so long -- no tracking.
  47.  
  48. > the code as is for as much as possible. I have spent countless hours
  49. > working with people who subscribe to the 'not invented here' syndrome.
  50. > 90% of those people could have used this code with absolutely no
  51.  
  52. I sense a bit of hostility here. I "invented" my own because yours was
  53. so, need I say it again, utterly and completely useless.
  54.  
  55. > if you can't use the code directly, it is usually simple enough for
  56. > somebody to extract the pieces they need for their application.
  57.  
  58. That's about all it is, a collection of pieces. Nothing holds it together.
  59.  
  60. > Obviously, the SDK does not have a lot of in-depth info on the patches
  61. > or how to implement them. That is not its primary focus. Most developers
  62.  
  63. Obviously? Is that some sort of reason why it's not there? Not it's primary
  64. focus? There's no focus. How's that? If you're going to do an SDK, why not
  65. do a complete one? This 2.10 thing is something I'd expect from a rag-tag
  66. organization.
  67.  
  68. > do not want to deal with that high of a level. If they do, MOST use
  69. > Ultramid, so they don't need to worry about the implementation details.
  70.  
  71. Who cares what most do? And I'd hardly call documenting the patches (and
  72. without numerous errors) "that high of a level". I'd call it a basic
  73. requirement. And, to follow your arguement, if "most" programmed for SBOS,
  74. would that mean there'd be an SDK on how to use SBOS and nothing else? (Silly
  75. premise, silly arguement). And if most are using ultramid.exe, a rather large
  76. and cumbersome TSR, then they are doing so because that's the only choice they
  77. have. It also means that they pretty much have to write to ultramidi and then
  78. write completely separate code to access other cards. Or are you under the
  79. impression that GUS developers only write for the GUS? Not likely, unless one
  80. likes to dismiss 99% of other users (the GUS having about 1% of the soundcard
  81. market, tops).
  82.  
  83. > We will probably add more info/examples in future SDKs.
  84.  
  85. What have you been doing the past year and a half? Maybe you people have
  86. been sitting on your high-horse too long. Come done in the trenches were
  87. your real support will be drawn from. When, in this next year, there are
  88. no new GUS-supported products out, relatively speaking, it's your job that
  89. goes out the window, not mine. Then again, being Forte, you can always go
  90. on to something else and just dump the GUS.
  91.  
  92. > I would like to thank Cornel for reviewing the doc. We NEED the feedback
  93. > so that we can make fixes/additions to the SDK to make it more useable.
  94. > If anybody else has any comments etc, please let us know. I can't promise
  95. > that we will be able to provide everything you want, but we'll try.
  96.  
  97. Just who is responsible for this? I'd like to see some names and e-mail
  98. addresses instead of this occasional, once-every-other-month pop-in by
  99.  
  100. > Forte Tech Support.
  101.  
  102. (ha!)
  103.  
  104. ------------------------------
  105.  
  106. End of GUS Programmer's Digest V7 #10
  107. *************************************
  108.  
  109. To post to tomorrow's digest:                    <gus-sdk@dsd.es.com>
  110. To (un)subscribe or get help:            <gus-sdk-request@dsd.es.com>
  111. To contact a human (last resort):          <gus-sdk-owner@dsd.es.com>
  112.  
  113. FTP sites:           archive.epas.utoronto.ca              /pub/pc/ultrasound
  114.                      wuarchive.wustl.edu            /systems/ibmpc/ultrasound
  115.                      archive.orst.edu                    /pub/packages/gravis
  116.                      theoris.rz.uni-konstanz.de                /pub/sound/gus
  117.                      nctuccca.edu.tw                           /PC/ultrasound
  118. FTP mail server:     mail-server@nike.rz.uni-konstanz.de
  119.  
  120. Hints:
  121.       - Get the FAQ from the FTP sites or the request server.
  122.       - Mail to <gus-sdk-request@dsd.es.com> for info about other GUS
  123.     related mailing lists (general use, musician's, etc.).
  124.  
  125.  
  126.